1. Field of the Invention
The present invention generally relates to buffer management, and more particularly to buffer management in vector graphics hardware.
2. Discussion of the Background
In recent years, vector graphics systems and algorithms have been developed for achieving robust and exact visualization, and have been employed in demanding software applications, such as in computer aided design, graphics applications, and the like. The benefit of the employing vector graphics, include scalability without the loss of graphics quality. The vector in a drawing or a plan typically includes a starting point, a direction, and a length or an ending point. Thus, a line can be represented using vector graphics with reduced information, as compared to having to indicate each pixel of the line, as with other methods. Furthermore, the vector need not be a direct line, as curves, and the like, also can be employed, and including additional information, for example, for defining a curve. The corresponding format employed during the execution of a corresponding graphical application, the file format for storing the corresponding graphical information, the fundamentals of vector graphics and the corresponding software applications employed, and the like, are well known and will not be described in detail herein.
In addition, certain graphics standards have been developed, such the OpenVG 1.0 standard by Khronos group of Jul. 28, 2005, incorporated by reference herein, and which includes an application programming interface (API) for hardware accelerated two-dimensional vector and raster graphics applications. The standard provides a device independent and vendor-neutral interface for sophisticated two-dimensional graphical applications, while allowing device manufacturers to provide hardware acceleration on devices ranging from wrist watches, to full microprocessor-based desktop systems, to server machines, and the like.
The standard provides an interface for a set of functions that can be implemented by hardware and/or software drivers for rasterization, filling of polygons, and the like. In the standard, two different fill rules, a non-zero and an odd/even rule, are implemented, and are described at page 72 of the standard. The basic principle of such filling technique employs the fact that each edge of a polygon has a direction, such that when the filling procedure arrives at the edge from the left, the filling procedure detects if the edge is going up or down. If the edge is going upwards, a counter is increased, and if the edge is going downwards, the counter is decreased. The value of the counter is stored in a buffer for each pixel on the screen. However, the pixels are further divided into sub-pixels, wherein the counter values must be stored for each line of each sub-pixel, requiring even larger buffers.
The above technique presents a problem for compact hardware implementations, and the like, and which may limit the buffer size, for example, due to manufacturing considerations, cost considerations, and the like. For example, if a mobile device has a display resolution of 176×208 pixels, and each pixel is divided into 16×16 sub-pixels, and an 8-bit counter is employed for each line, a buffer of 585728 bytes is needed. However, a buffer of such size may not be practical for integration on a graphics hardware accelerator of such a mobile device. Furthermore, merely adding more memory to the graphics hardware accelerator may not be practical, for example, due to the common evolvement in manufacturing processes, a need for bigger graphics resolutions, and the like.
One solution is to use the main memory of the device for implementing the above-noted buffer. However, such a solution results in increased traffic on limited bandwidth buses between the graphics accelerator and the main memory.